Some notes:

• After some tests, I am not sure we should highlight the shadowing functions. It makes the use of the printer a bit ambigious (ex: you might think that a function is shadowed, while its the shadowing function). We could use another color, but it's not necessary good to have too many code colors. Another solution is to write the canonical name of the shadowing function next to the shadowed function's name, any thoughts?

• We could do the same for the state variables. Right now, the derived contracts show all the state variables, while it could only show the new ones (and in red the shadowed ones, as it's probably a bug)

• My first idea of having detectors that are not 'calleable' from the cli command was a bad idea. We can probably just create a slither.utils.inheritance module with functions that provide the same info

For simplicity in distinguishing commits, the following changes have been since @montyly 's above post:

• Internal detectors were removed and logic was moved to slither.utils.inheritance_analysis. This provides functions to obtain all shadowing/shadowed function pairs.
  • detect_direct_function_shadowing(contract) will obtain all shadowing via direct line of inheritance for a given contract.
  • detect_c3_function_shadowing(contract) will obtain all indirect shadowing through C3 linearization.
  • detect_function_shadowing(contracts, direct_shadowing=True, indirect_shadowing=True) combines the results from each into pairs which more simplistically state what is shadowed, and what is shadowing. This is used to obtain clean results for the inheritance-graph printer.
• inheritance-graph was modified to only highlight shadowed functions.

TODO:

• Currently detect_function_shadowing returns overshadowed pairs for c3 linearization that may contain duplicates, while the same definition cannot actually appear more than once.
• Add state variable shadowing helpers to inheritance_analysis, plug it in to inheritance-graph.
• Determine how to connect shadowing vs shadowed functions (such that it is easy for users to read: coloring can become difficult to understand and not provide verbose-enough output for the user to distinguish what collisions are ocurring).

For documentation:

To this point, all TODO's are complete (save for the last). Additionally:
-If a contract has multiple inheritance, edges will be numbered in the order of declaration.
-Fixed a bug where special output formatting for state variables of type "Contract" would never be reached.

This PR is ready for review now. The final behavior for inheritance-graph is as follows:

• Edges are numbered according to order of inheritance.
• Variable shadowing will be shown in red.
• Direct function shadowing will be shown in orange.
• Additional information about indirect shadowing via c3 linearization will be shown in an additional text box at the bottom of any affected node.

Example:

Other supporting changes/bugfixes are detailed throughout this thread.